This document relates configuration and customizing data for executing multiple, independent instances of business application programs.
In a simplified model of executing a computer program such as a business application, there are three categories of information needed: the program code to be executed (operations); the application data to be processed (input and output data); and often additional configuration data (customizing data). Configuration data configure the application by fixing pre-defined properties of the program, such as the set of available functions, the way implemented functions behave, the user interface, or general user-specific settings (such as number and date/time format etc.). Configuration data make an application more flexible by changing certain properties or parameters of the application without modifying and recompiling the application.
In terms of abstraction configuration data lie somewhere between program code and application data. Configuration data can thus be classified and viewed as being more related to program operations (e.g., meta data that describes certain functional aspects of an application) or more related to application data (e.g., master data like units, ISO codes, or exchanges rates). Hence configuration data can be handled and processed in different ways: they can be evaluated during program compilation to optimize the coding according to the specific configuration settings, or they can be evaluated at program runtime in order to be used dynamically or to determine the program flow. Sometimes both approaches are used simultaneously to complement each other, exemplified by the kind of configuration data described in this document.
Business application programs are typically written and compiled according to a business application programming language such as the Advanced Business Application Programming (ABAP) language developed by SAP AG (Walldorf, Germany). The programming language ABAP features some mechanisms to support modification of the standard business coding necessary to integrate industry-specific or customer-specific requirements. This framework—known as the Enhancement and Switch Framework—has been used to retrofit industry-specific modifications back into the ERP standard coding, and to activate or deactivate those modifications dynamically to achieve industry-specific behavior of the business applications.
Within the ABAP switch framework, the ABAP modification code snippets—called “enhancements”—can be added to existing ABAP code at certain positions in the coding. Additionally, these enhancements can be switched on or off by setting separately stored switches. Depending on the switch setting, the corresponding enhancements are pre-processed by the ABAP compiler at compile-time and evaluated at run-time to decide whether or not the enhancement is to be executed. Accordingly, the switch settings serve to configure an application program dynamically. Generally speaking the switch values are configuration data for the business applications.
Those switch settings need to be adequately managed. The most significant requirements for the management of those switch settings include consistency and robustness of program execution, i.e. changes of switch settings must not influence running transactions, and all implicit and explicit accesses at runtime must deliver identical results. On the other hand time and space efficiency is very important. In particular, the time overhead for switch state queries must be as little as possible and should not have measurable effects on the performance of the business transaction. For reason of optimization, the switch settings can be evaluated statically at compile-time in order to adapt or prepare the target program code according to the switch settings.
This approach to managing any kind of configuration data originated within the switch framework which manages those switch settings as a special kind of configuration data. Within a typical software product portfolio, a large amount of configuration data for business applications—called “customizing data”—are used. Those customizing data can have very different characteristics and thus be processed in different ways, as discussed above. But for most kinds of configuration data this method can be applied.
Currently, customizing data are often simply read directly from a database at runtime of the application. There is no versioning, and the applications are not prevented from accessing modified customizing data which may lead to inconsistencies and adverse effects. Accordingly, robustness and consistency of business applications are suffering from modifying customizing data at runtime. Additionally, database access operations significantly decrease time efficiency. On the other hand if the configuration data is stored into the current program context identical configuration data is redundantly stored in every program instance because there is no sharing.